home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-snmpv2-coex-05.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
31KB
|
1,003 lines
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
Coexistence between version 1 and version 2 of the
Internet Network Management Framework
Tue Dec 22 13:43:46 1992 |
Jeffrey D. Case
SNMP Research, Inc.
University of Tennessee, Knoxville
case@cs.utk.edu
Keith McCloghrie
Hughes LAN Systems
kzm@hls.com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
Steven L. Waldbusser
Carnegie Mellon University
waldbusser@andrew.cmu.edu
Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".
Expires June 22, 1993 [Page 1]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
1. Introduction
The purpose of this document is to describe coexistence
between version 2 of the Internet-standard Network Management
Framework, termed the SNMP version 2 framework (SNMPv2) [1],
and the original Internet-standard Network Management
Framework (SNMPv1), which consists of these three documents:
RFC 1155 [2] which defines the Structure of Management
Information (SMI), the mechanisms used for describing and
naming objects for the purpose of management.
RFC 1212 [3] which defines a more concise description
mechanism, which is wholly consistent with the SMI.
RFC 1157 [4] which defines the Simple Network Management
Protocol (SNMP), the protocol used for network access to
managed objects.
Expires June 22, 1993 [Page 2]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
2. Management Information
The SNMPv2 approach towards describing collections of managed
objects is nearly a proper superset of the approach defined in
the Internet-standard Network Management Framework. For
example, both approaches use ASN.1 [5] as the basis for a
formal descriptive notation. Indeed, one might note that the
SNMPv2 approach largely codifies the existing practice for
defining MIB modules, based on extensive experience with the
current framework.
The SNMPv2 documents which deal with information modules are:
Structure of Management Information for SNMPv2 [6], which
defines concise notations for describing information
modules, managed objects and notifications;
Textual Conventions for SNMPv2 [7], which defines a
concise notation for describing textual conventions, and
also defines some initial conventions; and,
Conformance Statements for SNMPv2 [8], which defines
concise notation for describing compliance and
capabilities statements.
The following sections consider the three areas: MIB modules,
compliance statements, and capabilities statements.
MIB modules defined using the current framework may continue
to be used with the SNMPv2 protocol. However, for the MIB
modules to conform to the SNMPv2 framework, the following
changes are required:
2.1. Object Definitions
In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. Only if the
semantics of an object truly changes should deprecation be
performed.
(1) The IMPORTS statement must reference SNMPv2-SMI, instead
of RFC1155-SMI and RFC-1212.
Expires June 22, 1993 [Page 3]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
(2) The MODULE-IDENTITY macro must be invoked immediately
after any IMPORTs or EXPORTs statement.
(3) For any descriptor which contains the hyphen character,
the hyphen character is removed.
(4) For any object with an integer-valued SYNTAX clause, in
which the corresponding INTEGER does not have a range
restriction (i.e., the INTEGER has neither a defined set
of named-number enumerations nor an assignment of lower-
and upper-bounds on its value), the object must have the
value of its SYNTAX clause changed to Integer32.
(5) For any object with a SYNTAX clause value of an
enumerated INTEGER, the hyphen character is removed from
any named-number labels which contain the hyphen
character.
(6) For any object with a SYNTAX clause value of Counter, the
object must have the value of its SYNTAX clause changed
to Counter32.
(7) For any object with a SYNTAX clause value of Gauge, the
object must have the value of its SYNTAX clause changed
to Gauge32.
(8) For all objects, the ACCESS clause must be replaced by a
MAX-ACCESS clause. The value of the MAX-ACCESS clause is
the same as that of the ACCESS clause unless some other
value makes "protocol sense" as the maximal level of
access for the object. In particular, object types for
which instances can be explicitly created by a protocol
set operation, will have a MAX-ACCESS clause of "read-
create". If the value of the ACCESS clause is "write-
only", then the value of the MAX-ACCESS clause is "read-
write", and the DESCRIPTION clause notes that reading
this object will result implementation-specific results.
(9) For any columnar object which is used solely for instance
identification in a conceptual row, the object must have
the value of its MAX-ACCESS clause set to "not-
accessible", unless all columnar objects of the
conceptual row are used for instance identification, in
which case, the MAX-ACCESS clause for one of them must be
something other than "not-accessible".
Expires June 22, 1993 [Page 4]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
(10) For all objects, if the value of the STATUS clause is
"mandatory", the value must be replaced with "current".
(11) For all objects, if the value of the STATUS clause is
"optional", the value must be replaced with "obsolete".
(12) For any object not containing a DESCRIPTION clause, the
object must have a DESCRIPTION clause defined.
(13) For any object corresponding to a conceptual row which
does not have an INDEX clause, the object must have
either an INDEX clause or an AUGMENTS clause defined.
(14) For any object with an INDEX clause that references an
object with a syntax of NetworkAddress, the value of the
STATUS clause of the both objects is changed to
"obsolete".
(15) For any object containing a DEFVAL clause with an OBJECT
IDENTIFIER value which is expressed as a collection of
sub-identifiers, change the value to reference a single
ASN.1 identifier.
Other changes are desirable, but not necessary:
(1) Creation and deletion of conceptual rows is inconsistent
using the current framework. The SNMPv2 framework
corrects this. As such, if the MIB module undergoes
review early in its lifetime, and it contains conceptual
tables which allow creation and deletion of conceptual
rows, then it may be worthwhile to deprecate the objects
relating to those tables and replacing them with objects
defined using the new approach.
(2) For any object with a string-valued SYNTAX clause, in
which the corresponding OCTET STRING does not have a size
restriction (i.e., the OCTET STRING has no assignment of
lower- and upper-bounds on its length), one might
consider defining the bounds for the size of the object.
(3) For all textual conventions informally defined in the MIB
module, one might consider redefining those conventions
using the TEXTUAL-CONVENTION macro. Such a change would
not necessitate deprecating objects previously defined
using an informal textual convention.
Expires June 22, 1993 [Page 5]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
(4) For any object which represents a measurement in some
kind of units, one might consider adding a UNITS clause
to the definition of that object.
(5) For any conceptual row which is an extension of another
conceptual row, i.e., for which subordinate columnar
objects both exist and are identified via the same
semantics as the other conceptual row, one might consider
using an AUGMENTS clause in place of the INDEX clause for
the object corresponding to the conceptual row which is
an extension.
Finally, when encountering common errors in SNMPv1 MIB
modules:
(1) For any object with a SYNTAX clause value of an
enumerated INTEGER, if a named-number enumeration is
present with a value of zero, the value of the STATUS
clause of that object is changed to "obsolete".
(2) For any non-columnar object that is instanced as if it
were immediately subordinate to a conceptual row, the
value of the STATUS clause of that object is changed to
"obsolete".
(3) For any conceptual row object that is not contained
immediately subordinate to a conceptual table, the value
of the STATUS clause of that object (and all subordinate
objects) is changed to "obsolete".
2.2. Trap Definitions
If a MIB module is changed to conform to the SNMPv2 framework,
then each occurrence of the TRAP-TYPE macro must be changed to
a corresponding invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement must not reference RFC-1215.
(2) The ENTERPRISES clause must be removed.
(3) The VARIABLES clause must be renamed to the OBJECTS
clause.
Expires June 22, 1993 [Page 6]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
(4) The STATUS clause must be added.
(5) The value of an invocation of the NOTIFICATION-TYPE macro
is an OBJECT IDENTIFIER, not an INTEGER, and must be
changed accordingly.
2.3. Compliance Statements
For those information modules which are "standard", a
corresponding invocation of the MODULE-COMPLIANCE macro must
be included within the information module (or in a companion
information module), and any commentary text in the
information module which relates to compliance must be
removed. Typically this editing can occur when the
information module undergoes review.
2.4. Capabilities Statements
In the current framework, the informational document [9] uses
the MODULE-CONFORMANCE macro to describe an agent's
capabilities with respect to one or more MIB modules.
Converting such a description for use with the SNMPv2
framework requires these changes:
(1) Use the macro name AGENT-CAPABILITIES instead of MODULE-
CONFORMANCE.
(2) The STATUS clause must be added.
(3) For all occurrences of the CREATION-REQUIRES clause, note
the slight change in semantics, and omit this clause if
appropriate.
Expires June 22, 1993 [Page 7]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
3. Protocol Operations
The SNMPv2 documents which deal with protocol operations are:
Protocol Operations for SNMPv2 [10], which defines the
syntax and semantics of the operations conveyed by the
protocol; and,
Transport Mappings for SNMPv2 [11], which defines how the
protocol operations are carried over different transport
services.
The following section considers two areas: the proxy behavior
between a SNMPv2 entity and a SNMPv1 agent; and, the behavior
of "bi-lingual" protocol entities acting in a manager role.
3.1. Proxy Agent Behavior
To achieve coexistence at the protocol-level, a proxy
mechanism may be used. A SNMPv2 entity acting in an agent
role may be implemented and configured to act in the role of a
proxy agent.
3.1.1. SNMPv2 -> SNMPv1
When converting requests from a SNMPv2 entity acting in a
manager role into requests sent to a SNMPv1 entity acting in
an agent role:
(1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-
PDU is received, then it is passed unaltered by the proxy
agent.
(2) If a GetBulkRequest-PDU is received, the proxy agent sets
the non-repeaters and max-repetitions fields to zero, and
sets the tag of the PDU to GetNextRequest-PDU.
3.1.2. SNMPv1 -> SNMPv2
When converting responses received from a SNMPv1 entity acting
in an agent role into responses sent to a SNMPv2 entity acting
in a manager role:
Expires June 22, 1993 [Page 8]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
(1) If a GetResponse-PDU is received, then it is passed
unaltered by the proxy agent. Note that even though a
SNMPv2 entity will never generate a Response-PDU with a
error-status field having a value of `noSuchName',
`badValue', or `readOnly', the proxy agent must not
change this field. This allows the SNMPv2 entity acting
in a manager role to interpret the response correctly.
If a GetResponse-PDU is received with an error-status
field having a value of `tooBig', the proxy agent will
remove the contents of the variable-bindings field before
propagating the response. Note that even though a SNMPv2
entity will never generate a `tooBig' in response to a
GetBulkRequestPDU, the proxy agent must propagate such a
response.
(2) If a Trap-PDU is received, then it is mapped into a
SNMPv2-Trap-PDU. This is done by prepending onto the
variable-bindings field two new bindings: sysUpTime.0
[12], which takes its value from the timestamp field of
the Trap-PDU; and, snmpTrapOID.0 [13], which is
calculated thusly: if the value of generic-trap field is
`enterpriseSpecific', then the value used is the
concatenation of the enterprise field from the Trap-PDU
with two additional sub-identifiers, `0', and the value
of the specific-trap field; otherwise, the value of the
corresponding trap defined in [13] is used. (For
example, if the value of the generic-trap field is
`coldStart', then the coldStart trap [13] is used.) Then,
one new binding is appended onto the variable-bindings
field: snmpTrapEnterpriseOID.0 [13], which takes its
value from the enterprise field of the Trap-PDU. To
determine the destinations for the SNMPv2-Trap-PDU, the
proxy agent applies the procedures defined in Section
4.2.6 of [10], with the exception that no check is made
to see if the instances associated with this trap are
present in the proxy agent's view.
Expires June 22, 1993 [Page 9]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
3.2. Bi-lingual Manager Behavior
To achieve coexistence at the protocol-level, a protocol
entity acting in a manager role might support both SNMPv1 and
SNMPv2. When a management application needs to contact a
protocol entity acting in an agent role, the entity acting in
a manager role consults a local database to select the correct
management protocol to use.
In order to provide transparency to management applications,
the entity acting in a manager role must map operations as if
it were acting as a proxy agent.
Expires June 22, 1993 [Page 10]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
4. Acknowledgements
The comments of the SNMP version 2 working group are
gratefully acknowledged:
Beth Adams, Network Management Forum
Steve Alexander, INTERACTIVE Systems Corporation
David Arneson, Cabletron Systems
Toshiya Asaba,
Fred Baker, ACC
Jim Barnes, Xylogics, Inc.
Brian Bataille
Andy Bierman, SynOptics Communications, Inc.
Uri Blumenthal, IBM Corporation
Fred Bohle, Interlink
Jack Brown
Theodore Brunner, Bellcore
Stephen F. Bush, GE Information Services
Deirdre C. Kostik, Bellcore
Jeff Case, University of Tennessee, Knoxville
John Chang, IBM Corporation
Szusin Chen, Sun Microsystems
Robert Ching
Chris Chiotasso, Ungermann-Bass
Bobby A. Clay, NASA/Boeing
John Cooke, Chipcom
Tracy Cox, Bellcore
Juan Cruz, Datability, Inc.
David Cullerot, Cabletron Systems
Cathy Cunningham, Microcom
James R. (Chuck) Davin, Bellcore
Michael Davis, Clearpoint
Mike Davison, FiberCom
Cynthia DellaTorre, MITRE
Taso N. Devetzis, Bellcore
Manual Diaz, DAVID Systems, Inc.
Jon Dreyer, Sun Microsystems
Susan E. Hicks, Martin Marietta Energy Systems
David Engel, Optical Data Systems
Mike Erlinger, Lexcel
Roger Fajman, NIH
Daniel Fauvarque, Sun Microsystems
Karen Frisa, CMU
Shari Galitzer, MITRE
Shawn Gallagher, Digital Equipment Corporation
Expires June 22, 1993 [Page 11]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
Richard Graveman, Bellcore
Maria Greene, Xyplex, Inc.
Michel Guittet, Apple
Robert Gutierrez, NASA
Bill Hagerty, Cabletron Systems
Gary W. Haney, Martin Marietta Energy Systems
Patrick Hanil, Nokia Telecommunications
Matt Hecht, SNMP Research, Inc.
Edward A. Heiner, Jr., Synernetics Inc.
Geral Holzhauer, Apple
John Hopprich, DAVID Systems, Inc.
Jeff Hughes, Hewlett-Packard
Robin Iddon, Axon Networks, Inc.
David Itusak
Kevin M. Jackson, Concord Communications, Inc.
Ole J. Jacobsen, Interop Company
Ronald Jacoby, Silicon Graphics, Inc.
Satish Joshi, SynOptics Communications, Inc.
Frank Kastenholz, FTP Software
Mark Kepke, Hewlett-Packard
Ken Key, SNMP Research, Inc.
Zbiginew Kielczewski, Eicon
Jongyeoi Kim
Andrew Knutsen, The Santa Cruz Operation
Michael L Kornegay, VisiSoft
Cheryl Krupczak, Georgia Tech
Steven L. Waldbusser, Carnegie Mellon Universitty
Mark S. Lewis, Telebit
David Lin
David Lindemulder, AT&T/NCR
Ben Lisowski, Sprint
David Liu, Bell-Northern Research
John Lunny, The Wollongong Group
Robert C. Lushbaugh Martin, Marietta Energy Systems
Michael Luufer, BBN
Carl Madison, Star-Tek, Inc.
Keith McCloghrie, Hughes LAN Systems
Evan McGinnis, 3Com Corporation
Bill McKenzie, IBM Corporation
Donna McMaster, SynOptics Communications, Inc.
John Medicke, IBM Corporation
Doug Miller, Telebit
Dave Minnich, FiberCom
Mohammad Mirhakkak, MITRE
Rohit Mital, Protools
Expires June 22, 1993 [Page 12]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
George Mouradian, AT&T Bell Labs
Patrick Mullaney, Cabletron Systems
Dan Myers, 3Com Corporation
Rina Nathaniel, Rad Network Devices Ltd.
Hien V. Nguyen, Sprint
Mo Nikain
Tom Nisbet
William B. Norton, MERIT
Steve Onishi, Wellfleet Communications, Inc.
David T. Perkins, SynOptics Communications, Inc.
Carl Powell, BBN
Ilan Raab, SynOptics Communications, Inc.
RIchard Ramons, AT&T
Venkat D. Rangan, Metric Network Systems, Inc.
Louise Reingold, Sprint
Sam Roberts, Farallon Computing, Inc.
Kary Robertson, Concord Communications, Inc.
Dan Romascanu, Lannet Data Communications Ltd.
Marshall T. Rose, Dover Beach Consulting, Inc.
Shawn A. Routhier, Epilogue Technology Corporation
Chris Rozman
Asaf Rubissa, Fibronics
Jon Saperia, Digital Equipment Corporation
Michael Sapich
Mike Scanlon, Interlan
Sam Schaen, MITRE
John Seligson, Ultra Network Technologies
Paul A. Serice, Corporation for Open Systems
Chris Shaw, Banyan Systems
Timon Sloane
Robert Snyder, Cisco Systems
Joo Young Song
Roy Spitier, Sprint
Einar Stefferud, Network Management Associates
John Stephens, Cayman Systems, Inc.
Bob Stewart, Xyplex, Inc. (chair)
Kaj Tesink, Bellcore
Dean Throop, Data General
Ahmet Tuncay, France Telecom-CNET
Maurice Turcotte, Racal Datacom
Warren Vik, INTERACTIVE Systems Corporation
Yannis Viniotis
Steve Waldbusser, CMU
Timothy M. Walden, ACC
Alice Wang, Sun Microsystems
Expires June 22, 1993 [Page 13]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
James Watt, Newbridge
Luanne Waul, Timeplex
Donald E. Westlake III, Digital Equipment Corporation
Gerry White
Bert Wijnen, IBM Corporation
Peter Wilson, 3Com Corporation
Steven Wong, Digital Equipment Corporation
Randy Worzella, IBM Corporation
Daniel Woycke, MITRE
Honda Wu
Jeff Yarnell, Protools
Chris Young, Cabletron
Kiho Yum, 3Com Corporation
Expires June 22, 1993 [Page 14]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
5. References
[1] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Introduction to version 2 of the Internet-standard
Network Management Framework. Internet-Draft, (December |
22, 1992). |
[2] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets.
Request for Comments 1155, (May, 1990).
[3] M.T. Rose and K. McCloghrie, Concise MIB Definitions.
Request for Comments 1212, (March, 1991).
[4] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol. Request for Comments
1157, (May, 1990).
[5] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[6] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2). Internet-
Draft, (December 22, 1992). |
[7] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Textual Conventions for version 2 of the the Simple
Network Management Protocol (SNMPv2). Internet-Draft, |
(December 22, 1992). |
[8] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Conformance Statements for version 2 of the the Simple
Network Management Protocol (SNMPv2). Internet-Draft, |
(December 22, 1992). |
[9] K. McCloghrie, M.T. Rose, A Convention for Describing
SNMP-based Agents. Request for Comments 1303, (February,
1992).
[10] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Protocol Operations for version 2 of the Simple Network
Expires June 22, 1993 [Page 15]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
Management Protocol (SNMPv2). Internet-Draft, (December |
22, 1992). |
[11] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Transport Mappings for version 2 of the Simple Network
Management Protocol (SNMPv2). Internet-Draft, (December |
22, 1992). |
[12] K. McCloghrie and M.T. Rose, Management Information Base
for Network Management of TCP/IP-based internets: MIB-II.
Request for Comments 1213, (March, 1991).
[13] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Management Information Base for version 2 of the Simple
Network Management Protocol (SNMPv2). Internet-Draft, |
(December 22, 1992). |
Expires June 22, 1993 [Page 16]
Draft Coexistence between SNMPv1 and SNMPv2 Dec 92
Table of Contents
1 Introduction .......................................... 2
2 Management Information ................................ 3
2.1 Object Definitions .................................. 3
2.2 Trap Definitions .................................... 6
2.3 Compliance Statements ............................... 7
2.4 Capabilities Statements ............................. 7
3 Protocol Operations ................................... 8
3.1 Proxy Agent Behavior ................................ 8
3.1.1 SNMPv2 -> SNMPv1 .................................. 8
3.1.2 SNMPv1 -> SNMPv2 .................................. 8
3.2 Bi-lingual Manager Behavior ......................... 10
4 Acknowledgements ...................................... 11
5 References ............................................ 15
Expires June 22, 1993 [Page 17]